the_sims_2fandomcom-20200214-history
Help:Documenting groups in objects.package
"The objects.package archive hosts all the gameplay elements in the game. This includes not only objects purchasable in the catalogue and aspiration and career rewards, but also all Sim actions, job data, test objects, NPC templates, controllers, memory types, personality types, skills, aspirations, the Plumbbob, and so forth. This adds up to thousands upon thousands of files, and trying to document it from the top is a near-impossible task. Fortunately, game elements are divided into groups: files working directly with each other are grouped together (The exception being Semi-globals, which I will elaborate on in just a few paragraphs. By documenting the groups of an objects.package, future navigation, and thereby research, will thus be far simpler, and documenting this massive game will already be a far less daunting task than it was before. How do I do this? All you need is SimPE and a copy of whichever game you wish to document. In this case, I'll be using the 4-disc, pre-patch retail release of The Sims 2. Finding objects.package We want to find and copy objects.package to a folder on our computer for easy access. From the main directory, it is always located in "TSData/Res/Objects/objects.package". Depending on whether you're grabbing it from an already-installed game or your game disc, however, the process is slightly different. Copying from the disc On the game disc, the game files are stored in a ZIP-file, "compressed.zip". For the 4-disc release, this is located on disc 4 (The Yellow Disc). From there, it is located as described above. Copying from the installation folder The default installation of The Sims 2 is "C:\Program Files (x86)\EA Games\The Sims 2", from there, obj.package is located as described above. For The Ultimate Collection, the default location is "C:\Program Files (x86)\Origin Games\The Sims 2 Ultimate Collection\Base". Using SimPE to document objects.package After copying objects.package to a safe folder, open it with SimPE. Once it is open, order the contents by group by pressing the "Group" column head. Open a spreadsheet such as Google Sheets or Office Excel and use it to save your progress. Decide what information should be written in what column by considering the section below, and use the first row for headers. What should I DEFINITELY write down? First of all, many files in expansion packs and standalone games are copied over from the base game and earlier packs, so to save yourself some work and provide more clarity for future referencers, you can cross-reference with other objects.package documentations and, if the group is redundant, mark this in some manner. You could, for instance, if the group already appeared in University, write "EP1" in a column reserved for notes. The most important part to document is the group number and what it pertains to. In many cases, what it pertains to can easily be deciphered from a named OBJD or NREF file in the group. If none are present, it is very likely a semi global, and you may want to crossreference from a list of semiglobals. If you want to leave this to other people, you can get an approximate idea of what the group pertains to by scouring STR# or TTAs files, which contain text describing functions and attributes used in the group, or by perusing BHAVs which, though occasionally quite opaque in their structure, may clue you in through their titles as to what they do. What could I write down IF I WANT TO? To help future archeologists, you can reserve additional columns for other useful information you may come across along the way. This can include: NREF The NREF file contains a name describing the object, but more importantly, the wrapper writes up the group number so you don't have to go into the Resource tab to get it! OBJD OBJD files determine which categories of the Buy menu objects appear in. They also contain the internal names of objects, a hexadecimal determining the object type, and most importantly their GUIDs. GUIDs are how objects are referenced in the code and are therefore EXTREMELY useful to have documented. However, here are a couple of things to consider: #An OBJD can list several different GUIDs at once. ##There's a primary GUID and a Fallback GUID, which are usually the same. If this is not the case, it is recommended that you write a note of this in the note column ##There's an Original GUID listed between these, which, in the case of groups with several OBJDs (I will elaborate on these in 2.) may refer to one of the other GUIDS in the group, but most of the time it is not clear which object this refers to, if any. #A group may contain several OBJDs at once. This is typically the case for multi-tile objects, and in many cases these will have a parent OBJD, which contains the "correct" GUID. The parent OBJD is typically the one which doesn't have numbers at the end. It is most recommended that among all this information, you document the name of the parent OBJD and the primary GUID of the object, but documenting the Original GUID is also appreciated as this may prove valuable in the future as well. If you can't determine exactly which OBJD is the parent, you are allowed to make a guess as long as you note this in the note column. Catalog Description (CTSS) These contain the in-game names and descriptions of objects and Sims when moused over, picked up or bought in Buy mode. This can be very useful for identifying the objects later. The descriptions of the strings housed in these files contain developer notes, including which translation batch they were part of, which is an interesting piece of history worth documenting. Menu Strings (TTAs) These are similar to the above in that they also contain translation batch info. These are the names of actions which appear when moused over in the Action Queue. In the case of Social Interactions, there is no CTSS, so these are the main way of identifying those, and thus similarly important to document in those cases. semi global file (GLOB) These refer to the Semi Globals mentioned earlier. They contain the name of the Semi Global and its group. These are useful for identifying Semi Globals later, and saving the names would prove interesting just in case there are inconsistencies. Turning your spreadsheet into a table Once you've collected all the data into a fancy spreadsheet, it's time to format it for FANDOM. To do this, you need a simple, fast writing program like Notepad, and one which can make bulk text replacements with special symbols. In this tutorial, it'll be Word. Making the header Select all your data in the spreadsheet and copy it into Notepad. Go through the headers and add "! ", space included, instead of the tabulator spaces. Writing a table for FANDOM Source Next, Select All and copy into a Word document. The result is not pretty, but we only need it there temporarily. Open the Replace tool. In FANDOM, each row in a sortable table is designated by a horisontal line and a dash, like so "|-", standing on a line by itself. Therefore, we need to replace each line shift with such a setup. A lineshift is written as "^p" in the "Find what" and "Replace what" entries of the Replace tool. Thus, we need to write "^p" in the former and "^p|-^p" in the latter. In order to help check if the document comes out right, you can press the pilcrow (¶) symbol in the toolbar of the main Word window. Click "Replace All" to make the change. Each cell in the source code of a FANDOM table is designated by a horizontal line preceding the actual content of the cell, situated on it's own line, while in the spreadsheet format, it is designated by a tabulator space (the space created when you press the "Tab" button in most text editors). Thus, we need to replace the tabulator spaces in the document with line shifts and horisontal lines. A tabulator space is written as "^t" in the "Find what" and "Replace what" spaces, so we need to write "^t" in the former and "^p|" in the latter this time. Once again, click "Replace All", then copy the entire document back into a better editor to make some final adjustments: Insert " " at the end. The former is used by the FANDOM compiler to determine that it's supposed to interpret the following code as a sortable table; the latter tells it to stop from that point on. Importing the table into a FANDOM article It is highly recommended to host a table of .package contents on it's own page, as it takes up a large amount of space. If you haven't already, create a new article and enter the Source editor from the Visual editor. Copy the text into the source editor and enter the visual editor to ensure that it looks correct. Publish the article and you're done! Notes These tables will typically NOT be mobile friendly. It may be advised to create sub-pages dividing the contents up on several pages. More details will follow soon.